Temporary or partial offloading of mobile application functions to a cloud-based environment

ABSTRACT

Techniques for temporarily and/or partially offloading mobile applications to one or more remote virtual machines in a server include establishing an application copy of a mobile application installed on a mobile device at a remote virtual machine, suspending the mobile application on the mobile device and offloading operations of the mobile application to the application copy at the remote virtual machine for a period of time. Suspending the mobile application and offloading its operations to the remote virtual machine for the period of time reduces consumption of resources on the mobile device. The virtual machine executes the application copy in the same manner the mobile device would execute the mobile application and transfers data from the execution to the mobile application at the end of the period of time to allow the mobile application to update itself and resume its operation without any loss of data or functionality.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/253,740 titled “TEMPORARY OR PARTIAL OFFLOADING OF MOBILE APPLICATIONFUNCTIONS TO A CLOUD-BASED ENVIRONMENT” filed on Apr. 15, 2014, beingissued as U.S. Pat. No. 9,830,191 on Nov. 28, 2017, which claimspriority to and benefit from U.S. Provisional Patent Application Ser.No. 61/812,149 titled “TEMPORARY OR PARTIAL OFFLOADING OF MOBILEAPPLICATION FUNCTIONS TO A CLOUD-BASED ENVIRONMENT” filed on Apr. 15,2013, which are expressly incorporated by reference herein.

BACKGROUND

A typical mobile device has multiple mobile applications installed onit. Many of these mobile applications connect to the network regularlyto fetch updates, advertisements or other data from their applicationservers and/or upload data to their application servers. Many of thesemobile applications, if not closed, continue running in the backgroundand perform these fetching and uploading tasks, even when they are notbeing used by the user. As a result, these mobile applications can causethe battery of the mobile device to drain much faster than normal.Moreover, these mobile applications with their constantuploading/downloading behavior can also cause unexpected high datausage. These and other negative behaviors of many mobile applicationsare undesirable.

BRIEF DESCRIPTION OF THE DRAWINGS

The present embodiments are illustrated by way of example and are notintended to be limited by the figures of the accompanying drawings. Inthe drawings:

FIG. 1A depicts a diagram illustrating example resources, including anapplication offload engine and one or more remote virtual machines, thatimplement the mobile application function and/or operation dataoffloading techniques disclosed herein.

FIG. 1B depicts an example diagram of a system where a host serverfacilitates management of traffic, content caching, and/or resourceconservation, and/or mobile application offloading.

FIG. 1C depicts an example diagram of a proxy and cache systemdistributed between the host server and device which facilitates networktraffic management and/or mobile application offloading.

FIG. 1D depicts an example diagram of the logical architecture of adistributed proxy and cache system.

FIG. 1E depicts an example diagram showing the architecture of clientside components in a distributed proxy and cache system with anapplication offload engine implemented on the client-side proxy inaccordance with some embodiments.

FIG. 1F depicts an example diagram of the example components on theserver side of the distributed proxy and cache system with a remotevirtual machine implemented on the server-side proxy in accordance withsome embodiments.

FIG. 1G depicts an example diagram of a signaling optimizer of thedistributed proxy and cache system.

FIG. 1H depicts an example diagram of an example client-serverarchitecture of the distributed proxy and cache system.

FIG. 1I depicts an example diagram illustrating data flows betweenexample client side components in a distributed proxy and cache system.

FIG. 2 depicts example functional components of a mobile deviceimplementing the application function and/or operation data offloadingengine.

FIG. 3A depicts an example flow diagram illustrating a method of mobileapplication function and/or operation data offloading.

FIG. 3B depicts an example flow diagram illustrating a method ofexecuting a copy of a mobile application at a virtual machine.

FIG. 4 depicts a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

The same reference numbers and any acronyms identify elements or actswith the same or similar structure or functionality throughout thedrawings and specification for ease of understanding and convenience.

DETAILED DESCRIPTION

Techniques are disclosed for offloading mobile applications using one ormore remote virtual machines in a server cloud. The disclosed techniquesinclude suspending an application on a mobile device and transferringone or more operation data and/or functions of the suspended applicationto a remote virtual machine to establish an application copy operatingon the remote virtual machine as a surrogate or proxy of the suspendedapplication on the mobile device. The remote virtual machine can belocated on a server or a server cloud (“server”) that is remote to themobile device.

Among other advantages, embodiments disclosed herein provide thecapability of offloading mobile applications from a user's mobile deviceto a remote virtual machine that resides in a server cloud during aselect time period (e.g., during off-peak or late night hours), therebyreducing power and/or data consumption associated with those mobileapplication activities which are likely to draw no attention from theuser. For example, by offloading operations of one or more mobileapplications to one or more remote virtual machines, the resources ofthe server are used in lieu of the resources of the mobile device. Forexample, the virtual machines on the server perform the operations suchas polling application servers to fetch new or changed content or datainstead of the mobile device, and thus, the mobile device consumes lessbattery resources turning its radio on and off. The configuration data(e.g., data necessary to configure an application copy at the server)and the new or updated data that is transferred between the mobiledevice and the remote server can be compressed. Moreover, the new orupdated data can be transferred in a single operation to the mobiledevice. These transfer techniques utilize the bandwidth moreefficiently. Furthermore, since the virtual machines becomes the firstpoint of communication with the application servers, the virtualmachines can screen the new or changed data for malicious or undesirablecontent and protect the mobile device.

Embodiments of the present disclosure include a system and method ofoffloading operations of a mobile application. The method can compriseestablishing an application copy of a mobile application installed on amobile device at a remote virtual machine, suspending the mobileapplication on the mobile device and offloading operations of the mobileapplication to the application copy at the remote virtual machine for aperiod of time. In some embodiments, establishing the application copyof the mobile application on the mobile device at the remote virtualmachine includes transferring application data associated with themobile application to the remote virtual machine to facilitate theapplication copy to be executed on the remote virtual machine in thesame manner the mobile application would be executed on the mobiledevice. In some embodiments, the application copy is executed at theremote virtual machine to perform the operations of the mobileapplication. Such operations can include communicating with anapplication server associated with the mobile application to obtain newor changed data. In some embodiments, the received data including new orchanged data for updating the mobile application and data that istransferred to the remote virtual machine to establish the applicationcopy are compressed using one or more compression techniques to reducenetwork bandwidth consumption during the transfer.

The method can further comprise receiving data generated or obtained bythe application copy during the period of time the operations of themobile application was offloaded to the application copy and updatingthe mobile application with the received data. Upon updating the mobileapplication with the received data which can include new or changeddata, the method can resume the mobile application on the mobile device.

In some embodiments, suspending the mobile application and offloadingthe operations of the mobile application to the remote virtual machinefor the period of time reduces consumption of resources by the mobileapplication on the mobile device. In some embodiments, offloading theoperations of the mobile application to the application copy at theremote virtual machine for the period of time reduces consumption ofpower, data, memory and/or CPU resources by the mobile application onthe mobile device. In some embodiments, multiple mobile applications onthe mobile device can have application copies established at a serverhosting multiple remote virtual machines including the remote virtualmachine.

In some embodiments, the method can further comprise determining theperiod of time during which the operations of the mobile application areoffloaded to the application copy at the remote virtual machine based onat least one of: user instructions, user activity patterns or a state ofthe mobile application. In some embodiments, the method can includeselecting the mobile application from a plurality of mobile applicationson the mobile device for offloading based on user instructions. In otherembodiments, the method can include tracking resource consumption by aplurality of mobile applications on the mobile device and selecting themobile application for offloading based on the resource consumption thatis tracked.

Embodiments of the present disclosure include a mobile device that isconfigured to execute the methods of the present disclosure. Forexample, in some embodiments, a mobile device can transfer configurationdata corresponding to a mobile application on the mobile device to aremote server to establish a proxy of the mobile application on avirtual machine hosted by the remote server. The mobile device cansuspend the mobile application on the mobile device and offloadoperations of the mobile application to the proxy of the mobileapplication at the virtual machine for a period of time. Timing forsuspending the mobile application and offloading operations of themobile application can be determined based on user instructions,availability of resources on the mobile device, state of the mobileapplication or a combination thereof. The mobile device, in someembodiments, can receive application data corresponding to theoperations of the mobile application performed by the proxy of themobile application from the virtual machine, update the mobileapplication on the mobile device using the received application data andresume the mobile application following the update.

Embodiments of the present disclosure include a system configured toexecute any of the methods disclosed herein. For example, in someembodiments a system comprising a remote server or a server cloud canhost a virtual machine. The virtual machine can be configured to receiveconfiguration data to establish a copy of a mobile application installedon a mobile device and in response to receiving instructions, executethe copy of the mobile application for a period of time in the samemanner as the mobile device would execute the mobile application. Thevirtual machine can aggregate new or changed data from executing thecopy of the mobile application and at the end of the period of time,transfer the new or changed data that are aggregated to the mobileapplication on the mobile device. In some embodiments, the period oftime is included in the instructions and is determined based on userbehavior, user settings or a state of the mobile application.

In some embodiments, the mobile application remains in a paused orsuspended state during the period of time to reduce consumption ofresources by the mobile application on the mobile device. The new orchanged data that is transferred to the mobile application at the end ofthe period of time can update the mobile application and cause themobile application exit the paused state and resume normal operation. Insome embodiments, the virtual machine is one of multiple virtualmachines hosted by the remote server or server cloud and the multiplevirtual machines are configured to execute copies of mobile applicationsinstalled on multiple mobile devices.

The following description and drawings are illustrative and are not tobe construed as limiting. Numerous specific details are described toprovide a thorough understanding of the disclosure. However, in certaininstances, well-known or conventional details are not described in orderto avoid obscuring the description. References to one or an embodimentin the present disclosure can be, but not necessarily are, references tothe same embodiment; and, such references mean at least one of theembodiments.

Reference in this specification to “one embodiment” or “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiment is included in at least one embodimentof the disclosure. The appearances of the phrase “in one embodiment” invarious places in the specification are not necessarily all referring tothe same embodiment, nor are separate or alternative embodimentsmutually exclusive of other embodiments. Moreover, various features aredescribed which may be exhibited by some embodiments and not by others.Similarly, various requirements are described which may be requirementsfor some embodiments but not other embodiments.

The terms used in this specification generally have their ordinarymeanings in the art, within the context of the disclosure, and in thespecific context where each term is used. Certain terms that are used todescribe the disclosure are discussed below, or elsewhere in thespecification, to provide additional guidance to the practitionerregarding the description of the disclosure. For convenience, certainterms may be highlighted, for example using italics and/or quotationmarks. The use of highlighting has no influence on the scope and meaningof a term; the scope and meaning of a term is the same, in the samecontext, whether or not it is highlighted. It will be appreciated thatsame thing can be said in more than one way.

Consequently, alternative language and synonyms may be used for any oneor more of the terms discussed herein, nor is any special significanceto be placed upon whether or not a term is elaborated or discussedherein. Synonyms for certain terms are provided. A recital of one ormore synonyms does not exclude the use of other synonyms. The use ofexamples anywhere in this specification including examples of any termsdiscussed herein is illustrative only, and is not intended to furtherlimit the scope and meaning of the disclosure or of any exemplifiedterm. Likewise, the disclosure is not limited to various embodimentsgiven in this specification.

Without intent to limit the scope of the disclosure, examples ofinstruments, apparatus, methods and their related results according tothe embodiments of the present disclosure are given below. Note thattitles or subtitles may be used in the examples for convenience of areader, which in no way should limit the scope of the disclosure. Unlessotherwise defined, all technical and scientific terms used herein havethe same meaning as commonly understood by one of ordinary skill in theart to which this disclosure pertains. In the case of conflict, thepresent document, including definitions will control.

FIG. 1A depicts a diagram 100A illustrating example resources thatimplement the mobile application offloading techniques disclosed herein.Included in the diagram 100A is a mobile device 150, a server 111,third-party servers 119A-N, and a communications network 117.

The server 111 may be a host server that facilitates management oftraffic, content caching, and/or resource conservation (e.g., the hostserver 100, described in FIG. 1B below) or another server 111 that isfully or partially, physically or functionally, separate from the hostserver 100. Depending on the embodiments, this separate server 111and/or the functions performed thereby may be a portion of the hostserver 100, or it may be hosted by a third party (e.g., any of thethird-party servers 119A-N).

As an additional or an alternative embodiment, any one of thethird-party servers 119A-N comprises the server 111. In one of suchembodiments, a respective third-party server (e.g., third-party server119A) may host a remote virtual machine for a corresponding application(e.g., application 102A) on a mobile device (e.g., mobile device 150).For example, the third-party server 119A can include a mobileapplication hosting server which provides the interactions and/orfunctions for the corresponding application 102A, which is accessed viaor at the mobile and/or other devices coupled to the network 117. Thethird-party server 119A can function as the server 111 and host virtualmachines for one or more mobile devices in performing the applicationfunction and/or operation data offloading techniques discussed herein.

Applications 102A-N are example applications of the mobile device 150.Applications 102A-N accessed on or via the mobile device 150 cancommunicate directly with the third-party servers 119A-N via the network117. Some examples of applications 102A-N include news applications,weather services, email clients, gaming applications, productivityapplications, feeds, mapping applications, readers, entertainmentapplications, multimedia applications, and/or social networkapplications. In general, mobile applications 102A-N have content anddata relevant or necessary to the operations of the application. Theseapplications 102A-N routinely communicate with the third-party servers119A-N (e.g., via polling techniques) for any update, and receive theupdates and/or content via the network 117, using radio communicationmodules (not shown in FIG. 1A).

The embodiments disclosed herein recognize that, as the computing andstorage resources on mobile devices become more powerful than ever, soare the power and data consumption associated with generating andcommunicating these data. Indeed, there is an increased multitude ofapplications running on mobile devices such as mobile device 150, andeach application consumes more and more resources including, forexample, central processing unit(s), memory space, battery power,network bandwidth, and so on. From a practical standpoint, many datasubscription services purchased by users of mobile devices also chargetheir fees (sometimes exponentially) by the amount of data used, andtherefore a reduction in unnecessary data consumption is desirable.

According to the embodiments provided herein, the mobile device 150 canoffload mobile application function and/or operation data to a server(e.g., server 111, a third-party server 119A-N), which can reduceunnecessary power and/or data consumption on the mobile device 150 whilemaintaining functionalities and/or operations of the application. Insome embodiments, the server 111 can host a cloud-based environment andcan include, for example, remote virtual machines (RVM) 113A-N.

In some embodiments, the mobile device 150 includes an applicationoffload engine (AOE) 105 that can transfer functioning and/or operationdata of the applications 102A-N to a corresponding RVM 113A-N thatcorresponds to the mobile device 150. The transfer can occur for one ormore time periods that are determined (e.g., by an application statemanager 107) as appropriate or desirable. When the transfer isinitiated, the application offload engine can suspend, pause, orotherwise fully or partially stop the functioning of the application onthe mobile device 150. The functions and/or operation data of eachapplication (e.g., application 102A) on mobile device 150, after beingtransferred by application offload engine 105 (e.g., using a transfermanager 109), form a surrogate application copy (e.g., application copy115A) on the RVM 113A in the cloud environment hosted by the server 111.During the time periods, the application 102A on the mobile device 150remains dormant or suspended while its surrogate application copy 115Aon the RVM 113A becomes active and continues the application's normaloperation from the cloud (e.g., hosted by the server 111), including anyfunctions and/or interactions with the third-party servers (e.g.,third-party server 119A.

When the time period ends, application data generated through operationof the application copy 115A during the time period can be in part or inwhole sent back to the mobile device 150. The application offload engine105 can update the suspended application 102A according to data that aretransferred back. Thereafter, the application offload engine 105 canresume the application 102A on the mobile device. By offloading mobileapplications from the mobile device 150 to the server 111 during thosetime periods, for example, which draw no attention from the user, orotherwise is not in use or is inactive or in the background, theapplication offload engine 105 and the RVM can reduce power and/or dataconsumption associated with mobile application activities whilemaintaining the application's normal operations.

In addition to or as an alternative to transferring the functions of theapplication 102A, some embodiments of the application offload engine 105can transfer a duplicate software copy of the application 102A to theRVM 113A. In some other embodiments, only updates or changes to theapplication data is transferred back. These and various otherembodiments and implementations of the disclosed offloading techniquesare described in more details below.

FIG. 1B illustrates an example diagram of a system where a host server100 facilitates management of traffic, content caching, and/or resourceconservation and/or mobile application offloading between mobile devices(e.g., wireless devices 150), and an application server or contentprovider 110, or other servers such as an ad server 120A, promotionalcontent server 120B, or an e-coupon server 120C in a wireless network(or broadband network) for resource conservation. The host server 100can further interact with mobile or client devices 150 for gettingreports and/or updates on resource usage, savings, and the like.

The client devices 150 can be any system and/or device, and/or anycombination of devices/systems that is able to establish a connection,including wired, wireless, cellular connections with another device, aserver and/or other systems such as host server 100 and/or applicationserver/content provider 110. Client devices 150 typically include adisplay and/or other output functionalities to present information anddata exchanged between among the mobile devices 150 and/or the hostserver 100 and/or application server/content provider 110. Theapplication server/content provider 110 can by any server includingthird party servers or service/content providers further includingadvertisement, promotional content, publication, or electronic couponservers or services. Similarly, separate advertisement servers 120A,promotional content servers 120B, and/or e-Coupon servers 120C asapplication servers or content providers are illustrated by way ofexample.

For example, the client devices 150 can include mobile, hand held orportable devices, wireless devices, or non-portable devices and can beany of, but not limited to, a server desktop, a desktop computer, acomputer cluster, or portable devices, including a notebook, a laptopcomputer, a handheld computer, a palmtop computer, a mobile phone, acell phone, a smart phone, a PDA, a Blackberry device, a Palm device, ahandheld tablet (e.g., an iPad or any other tablet), a hand heldconsole, a hand held gaming device or console, any SuperPhone such asthe iPhone, and/or any other portable, mobile, hand held devices, orfixed wireless interface such as a M2M device, etc. In one embodiment,the client devices 150, host server 100, and application server 110 arecoupled via a network 106 and/or a network 108. In some embodiments, thedevices 150 and host server 100 may be directly connected to oneanother.

The input mechanism on client devices 150 can include touch screenkeypad (including single touch, multi-touch, gesture sensing in 2D or3D, etc.), a physical keypad, a mouse, a pointer, a track pad, motiondetector (e.g., including 1-axis, 2-axis, 3-axis accelerometer, etc.), alight sensor, capacitance sensor, resistance sensor, temperature sensor,proximity sensor, a piezoelectric device, device orientation detector(e.g., electronic compass, tilt sensor, rotation sensor, gyroscope,accelerometer), or a combination of the above.

Signals received or detected indicating user activity at client devices150 through one or more of the above input mechanism, or others, can beused in the disclosed technology in acquiring context awareness at theclient device 150. Context awareness at client devices 150 generallyincludes, by way of example but not limitation, client device 150operation or state acknowledgement, management, useractivity/behavior/interaction awareness, detection, sensing, tracking,trending, and/or application (e.g., mobile applications) type, behavior,activity, operating state, etc.

Context awareness in the present disclosure also includes knowledge anddetection of network side contextual data and can include networkinformation such as network capacity, bandwidth, traffic, type ofnetwork/connectivity, and/or any other operational state data and/ormobile application loading and/or activities. Network side contextualdata can be received from and/or queried from network service providers(e.g., cell provider 112 and/or Internet service providers) of thenetwork 106 and/or network 108 (e.g., by the host server and/or devices150). In addition to application context awareness as determined fromthe client 150 side, the application context awareness may also bereceived from or obtained/queried from the respectiveapplication/service providers 110 (by the host 100 and/or client devices150).

The host server 100 can use, for example, contextual informationobtained for client devices 150, networks 106/108, applications (e.g.,mobile applications), application server/provider 110, or anycombination of the above, to manage the traffic in the system to satisfydata needs of the client devices 150 (e.g., to satisfy application orany other request including HTTP request). In one embodiment, thetraffic is managed by the host server 100 to satisfy data requests madein response to explicit or non-explicit user requests and/ordevice/application maintenance tasks. The traffic can be managed suchthat network consumption, for example, use of the cellular network isconserved for effective and efficient bandwidth utilization. Inaddition, the host server 100 can manage and coordinate such traffic inthe system such that use of mobile device 150 side resources (e.g.,including but not limited to battery power consumption, radio use,processor/memory use) are optimized with a general philosophy forresource conservation while still optimizing performance and userexperience.

For example, in context of battery conservation, the mobile device 150can observe user activity (for example, by observing user keystrokes,backlight status, or other signals via one or more input mechanisms,etc.) and alters device 150 behaviors. The mobile device 150 can alsorequest the host server 100 to alter the behavior for network resourceconsumption based on user activity or behavior.

In one embodiment, the traffic management for resource conservationand/or mobile application offloading are performed using a distributedsystem between the host server 100 and client device 150. Thedistributed system can include proxy server and cache components on theserver side 100 and on the device/client side, for example, as shown bythe server cache 135 on the server 100 side and the local cache 185 onthe client 150 side.

Functions and techniques disclosed for context aware traffic managementand/or mobile application offloading for resource conservation innetworks (e.g., network 106 and/or 108) and devices 150, can reside in adistributed proxy and cache system. The proxy and cache system can bedistributed between, and reside on, a given client device 150 in part orin whole and/or host server 100 in part or in whole. The distributedproxy and cache system are illustrated with further reference to theexample diagram shown in FIG. 1C. Notably, in some embodiments of suchsystems, the host server 100 can include the server 111 (FIG. 1A), theapplication server 110 can include the third-party servers (e.g.,third-party server 119A in FIG. 1A), and/or the mobile device 150 caninclude the mobile device 150 (FIG. 1A).

In one embodiment, client devices 150 communicate with the host server100 and/or the application server 110 over network 106, which can be acellular network and/or a broadband network. To facilitate overalltraffic management and/or mobile application offloading between devices150 and various application servers/content providers 110 to implementnetwork (bandwidth utilization) and device resource (e.g., batteryconsumption), the host server 100 can communicate with the applicationserver/providers 110 over the network 108, which can include theInternet (e.g., a broadband network).

In general, the networks 106 and/or 108, over which the client devices150, the host server 100, and/or application server 110 communicate, maybe a cellular network, a broadband network, a telephonic network, anopen network, such as the Internet, or a private network, such as anintranet and/or the extranet, or any combination thereof. For example,the Internet can provide file transfer, remote log in, email, news, RSS,cloud-based services, instant messaging, visual voicemail, push mail,VoIP, and other services through any known or convenient protocol, suchas, but is not limited to the TCP/IP protocol, UDP, HTTP, DNS, FTP,UPnP, NSF, ISDN, PDH, RS-232, SDH, SONET, etc.

The networks 106 and/or 108 can be any collection of distinct networksoperating wholly or partially in conjunction to provide connectivity tothe client devices 150 and the host server 100 and may appear as one ormore networks to the serviced systems and devices. In one embodiment,communications to and from the client devices 150 can be achieved by, anopen network, such as the Internet, or a private network, broadbandnetwork, such as an intranet and/or the extranet. In one embodiment,communications can be achieved by a secure communications protocol, suchas secure sockets layer (SSL), or transport layer security (TLS).

In addition, communications can be achieved via one or more networks,such as, but are not limited to, one or more of WiMax, a Local AreaNetwork (LAN), Wireless Local Area Network (WLAN), a Personal areanetwork (PAN), a Campus area network (CAN), a Metropolitan area network(MAN), a Wide area network (WAN), a Wireless wide area network (WWAN),or any broadband network, and further enabled with technologies such as,by way of example, Global System for Mobile Communications (GSM),Personal Communications Service (PCS), Bluetooth, WiFi, Fixed WirelessData, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, LTE Advanced, mobileWiMax, WiMax 2, WirelessMAN-Advanced networks, enhanced data rates forGSM evolution (EDGE), General packet radio service (GPRS), enhancedGPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, UMTS-TDD, 1×RTT, EV-DO,messaging protocols such as, TCP/IP, SMS, MMS, extensible messaging andpresence protocol (XMPP), real time messaging protocol (RTMP), instantmessaging and presence protocol (IMPP), instant messaging, USSD, IRC, orany other wireless data networks, broadband networks, or messagingprotocols.

FIG. 1C illustrates an example diagram of a proxy and cache systemdistributed between the host server 100 and mobile device 150 whichfacilitates network traffic management and/or mobile applicationoffloading between the mobile device 150 and an application server orcontent provider 110, or other servers such as an ad server 120A,promotional content server 120B, or an e-coupon server 120C for resourceconservation and content caching. The proxy system distributed among thehost server 100 and the mobile device 150 can further track alarms,timers or other triggers implemented by applications on a device andresources used by such alarms, timers, or other triggers to determineassociations using which the proxy system can manipulate the alarms,timers or other triggers to occur at an optimal time to reduce resourceusage.

The distributed proxy and cache system can include, for example, theproxy server 125 (e.g., remote proxy) and the server cache, 135components on the server side. The server-side proxy 125 and cache 135can, as illustrated, reside internal to the host server 100. Inaddition, the proxy server 125 and cache 135 on the server-side can bepartially or wholly external to the host server 100 and in communicationvia one or more of the networks 106 and 108. For example, the proxyserver 125 may be external to the host server and the server cache 135may be maintained at the host server 100. Alternatively, the proxyserver 125 may be within the host server 100 while the server cache isexternal to the host server 100. In addition, each of the proxy server125 and the cache 135 may be partially internal to the host server 100and partially external to the host server 100. The applicationserver/content provider 110 can by any server including third partyservers or service/content providers further including advertisement,promotional content, publication, or electronic coupon servers orservices. Similarly, separate advertisement servers 120A, promotionalcontent servers 120B, and/or e-Coupon servers 120C as applicationservers or content providers are illustrated by way of example.

The distributed system can also, include, in one embodiment, client-sidecomponents, including by way of example but not limitation, a localproxy 175 (e.g., a mobile client on a mobile device) and/or a localcache 185, which can, as illustrated, reside internal to the mobiledevice 150 (e.g., a mobile device).

In addition, the client-side proxy 175 and local cache 185 can bepartially or wholly external to the mobile device 150 and incommunication via one or more of the networks 106 and 108. For example,the local proxy 175 may be external to the mobile device 150 and thelocal cache 185 may be maintained at the mobile device 150.Alternatively, the local proxy 175 may be within the mobile device 150while the local cache 185 is external to the mobile device 150. Inaddition, each of the client-side proxy 175 and the cache 185 may bepartially internal to the host server 100 and partially external to thehost server 100.

In one embodiment, the distributed system can include an optionalcaching proxy server 199. The caching proxy server 199 can be acomponent which is operated by the application server/content provider110, the host server 100, or a network service provider 112, and or anycombination of the above to facilitate network traffic management fornetwork and device resource conservation. Proxy server 199 can be used,for example, for caching content to be provided to the mobile device150, for example, from one or more of, the application server/provider110, host server 100, and/or a network service provider 112. Contentcaching can also be entirely or partially performed by the remote proxy125 to satisfy application requests or other data requests at the mobiledevice 150.

In context aware traffic management and optimization for resourceconservation in a network (e.g., cellular or other wireless networks),characteristics of user activity/behavior and/or application behavior ata mobile device (e.g., any wireless device) 150 can be tracked by thelocal proxy 175 and communicated, over the network 106 to the proxyserver 125 component in the host server 100, for example, as connectionmetadata. The proxy server 125 which in turn is coupled to theapplication server/provider 110 provides content and data to satisfyrequests made at the mobile device 150.

In addition, the local proxy 175 can identify and retrieve mobile deviceproperties, including one or more of, battery level, network that thedevice is registered on, radio state, or whether the mobile device isbeing used (e.g., interacted with by a user). In some instances, thelocal proxy 175 can delay, expedite (prefetch), and/or modify data priorto transmission to the proxy server 125, when appropriate.

The local database 185 can be included in the local proxy 175 or coupledto the local proxy 175 and can be queried for a locally stored responseto the data request prior to the data request being forwarded on to theproxy server 125. Locally cached responses can be used by the localproxy 175 to satisfy certain application requests of the mobile device150, by retrieving cached content stored in the cache storage 185, whenthe cached content is still valid.

Similarly, the proxy server 125 of the host server 100 can also delay,expedite, or modify data from the local proxy prior to transmission tothe content sources (e.g., the application server/content provider 110).In addition, the proxy server 125 uses device properties and connectionmetadata to generate rules for satisfying request of applications on themobile device 150. The proxy server 125 can gather real time trafficinformation about requests of applications for later use in optimizingsimilar connections with the mobile device 150 or other mobile devices.

In general, the local proxy 175 and the proxy server 125 are transparentto the multiple applications executing on the mobile device. The localproxy 175 is generally transparent to the operating system or platformof the mobile device and may or may not be specific to devicemanufacturers. In some instances, the local proxy 175 is optionallycustomizable in part or in whole to be device specific. In someembodiments, the local proxy 175 may be bundled into a wireless model, afirewall, and/or a router.

In one embodiment, the host server 100 can in some instances, utilizethe store and forward functions of a short message service center (SMSC)112, such as that provided by the network service provider, incommunicating with the mobile device 150 in achieving network trafficmanagement. Note that 112 can also utilize any other type of alternativechannel including USSD or other network control mechanisms. The hostserver 100 can forward content or HTTP responses to the SMSC 112 suchthat it is automatically forwarded to the mobile device 150 ifavailable, and for subsequent forwarding if the mobile device 150 is notcurrently available.

In general, the disclosed distributed proxy and cache system allowsoptimization of network usage, for example, by serving requests from thelocal cache 185, the local proxy 175 reduces the number of requests thatneed to be satisfied over the network 106. Further, the local proxy 175and the proxy server 125 may filter irrelevant data from thecommunicated data. In addition, the local proxy 175 and the proxy server125 can also accumulate low priority data and send it in batches toavoid the protocol overhead of sending individual data fragments. Thelocal proxy 175 and the proxy server 125 can also compress or transcodethe traffic, reducing the amount of data sent over the network 106and/or 108. The signaling traffic in the network 106 and/or 108 can bereduced, as the networks are now used less often and the network trafficcan be synchronized among individual applications.

With respect to the battery life of the mobile device 150, by servingapplication or content requests from the local cache 185, the localproxy 175 can reduce the number of times the radio module is powered up.The local proxy 175 and the proxy server 125 can work in conjunction toaccumulate low priority data and send it in batches to reduce the numberof times and/or amount of time when the radio is powered up. The localproxy 175 can synchronize the network use by performing the batched datatransfer for all connections simultaneously.

FIG. 1D illustrates an example diagram of the logical architecture of adistributed proxy and cache system.

The distributed system can include, for example the followingcomponents:

-   -   client-side proxy 175: a component installed in the Smartphone,        mobile device or wireless device 150 that interfaces with        device's operating system, as well as with data services and        applications installed in the device. The client-side proxy 175        is typically compliant with and able to operate with standard or        state of the art networking protocols.

The server-side proxy 125 can include one or more servers that caninterface with third party application servers (e.g., 199), mobileoperator's network (which can be proxy 199 or an additional server thatis not illustrated) and/or the client-side proxy 175. In general, theserver-side proxy 125 can be compliant with and is generally able tooperate with standard or state of the art networking protocols and/orspecifications for interacting with mobile network elements and/or thirdparty servers.

Reporting and Usage Analytics Server 174: The Reporting and UsageAnalytics system or component 174 can collect information from theclient side 175 and/or the server side 125 and provides the necessarytools for producing reports and usage analytics can used for analyzingtraffic and signaling data. Such analytics can be used by the proxysystem in managing/reducing network traffic or by the network operatorin monitoring their networks for possible improvements and enhancements.Note that the reporting and usage analytics system/component 174 asillustrated, may be a server separate from the server-side proxy 125, orit may be a component of the server-side proxy 125, residing partiallyor wholly therein.

FIG. 1E illustrates an example diagram showing the architecture ofclient side components in a distributed proxy and cache system.

The client side components of the client-side proxy 175 can includesoftware components or agents installed on the mobile device thatenables traffic optimization and performs the related functionalities onthe client side. Components of the client-side proxy 175 can operatetransparently for end users and applications 163. The client-side proxy175 can be installed on mobile devices for optimization to take place,and it can effectuate changes on the data routes. Once data routing ismodified, the client-side proxy 175 can respond to application requeststo service providers or host servers, in addition to or instead ofletting those applications 163 access data network directly. In general,applications 163 on the mobile device do not notice that the client-sideproxy 175 is responding to their requests. Some example components ofthe client-side proxy 175 are described as follows:

Device State Monitor 121: The device state monitor 121 can beresponsible for identifying several states and metrics in the device,such as network status, display status, battery level, etc. such thatthe remaining components in the client-side proxy 175 can operate andmake decisions according to device state, acting in an optimal way ineach state.

Application Offload Engine (AOE) 105: As described in relation to FIG.1A, the application offload engine 105 can perform, in conjunction witha Remote Virtual Machine (RVM) 179 (FIG. 1F, discussed below), themobile application offloading techniques disclosed herein. In theembodiment shown in FIG. 1E, the application offload engine 105 iscoupled to the device state monitor 121 to receive application activity,battery, network status, as well as user selection, an administrator'sselection, and/or other suitable information in determining time periodsfor performing the mobile application offloading. The AOE 105 can alsocommunicate with the server-side proxy 125 (FIG. 1F) for transferringthe functionalities and/or operation data of applications 163 (e.g.,applications 102, FIG. 1A) to and from the server 111.

Traffic Recognizer 122: The traffic recognizer 122 analyzes all trafficbetween the wireless device applications 163 and their respective hostservers in order to identify recurrent patterns. Supported transportprotocols include, for example, DNS, HTTP and HTTPS, such that trafficthrough those ports is directed to the client-side proxy 175. Whileanalyzing traffic, the client-side proxy 175 can identify recurringpolling patterns which can be candidates to be performed remotely by theserver-side proxy 125, and send to the protocol optimizer 123.

Protocol Optimizer 123: The protocol optimizer 123 can implement thelogic of serving recurrent request from the local cache 185 instead ofallowing those request go over the network to the serviceprovider/application host server. One is its tasks is to eliminate orminimize the need to send requests to the network, positively affectingnetwork congestion and device battery life.

Local Cache 185: The local cache 185 can store responses to recurrentrequests, and can be used by the Protocol Optimizer 123 to sendresponses to the applications 163.

Traffic Scheduler 124: The traffic scheduler 124 can temporally movecommunications to optimize usage of device resources by unifyingkeep-alive signaling so that some or all of the different applications163 can send keep-alive messages at the same time (traffic pipelining).Traffic scheduler 124 may also decide to delay transmission of data thatis not relevant at a given time (for example, when the device is notactively used).

Policy Manager 129: The policy manager 129 can store and enforce trafficoptimization and reporting policies provisioned by a Policy ManagementServer (PMS). At the client-side proxy 175 first start, trafficoptimization and reporting policies (policy profiles) that is to beenforced in a particular device can be provisioned by the PolicyManagement Server.

Watch Dog 127: The watch dog 127 can monitor the client-side proxy 175operating availability. In case the client-side proxy 175 is not workingdue to a failure or because it has been disabled, the watchdog 127 canreset DNS routing rules information and can restore original DNSsettings for the device to continue working until the client-side proxy175 service is restored.

Reporting Agent 126: The reporting agent 126 can gather informationabout the events taking place in the device and sends the information tothe Reporting Server. Event details are stored temporarily in the deviceand transferred to reporting server only when the data channel state isactive. If the client-side proxy 175 doesn't send records withintwenty-four hours, the reporting agent 126 may attempt to open theconnection and send recorded entries or, in case there are no entries instorage, an empty reporting packet. All reporting settings areconfigured in the policy management server.

Push Client 128: The push client 128 can be responsible for the trafficto between the server-side proxy 125 and the client-side proxy 175. Thepush client 128 can send out service requests like content updaterequests and policy update requests, and receives updates to thoserequests from the server-side proxy 125. In addition, push client 128can send data to a reporting server (e.g., the reporting and/or usageanalytics system which may be internal to or external to the server-sideproxy 125).

The proxy server 199 has a wide variety of uses, from speeding up a webserver by caching repeated requests, to caching web, DNS and othernetwork lookups for a group of clients sharing network resources. Theproxy server 199 is optional. The distributed proxy and cache system(e.g., the server-side proxy 125 and/or the client-side proxy 175)allows for a flexible proxy configuration using either the proxy 199,additional proxy(s) in operator's network, or integrating both proxies199 and an operator's or other third-party's proxy.

FIG. 1F illustrates a diagram of the example components on the serverside of the distributed proxy and cache system.

The server side 125 of the distributed system can include, for example arelay server 142, which interacts with a traffic harmonizer 144, apolling server 145 and/or a policy management server 143. Each of thevarious components can communicate with the client-side proxy 175, orother third party (e.g., application server/service provider 110 and/orother proxy 199) and/or a reporting and usage analytics system. Someexample components of the server-side proxy 125 is described as follows:

Relay Server 142: The relay server 142 is the routing agent in thedistributed proxy architecture. The relay server 142 manages connectionsand communications with components on the client-side proxy 175installed on devices and provides an administrative interface forreports, provisioning, platform setup, and so on.

Remote Virtual Machine (RVM) 179: Similar to what are mentioned withregard to FIG. 1A, the RVM 179 can perform, in conjunction withApplication Offload Engine (AOE) 177 (FIG. 1E), the mobile applicationoffloading techniques disclosed herein. In some embodiments, such as theone shown in FIG. 1F, the RVM 179 is coupled to the relay server 142 toreceive relevant connection and communication information for performingthe mobile application offloading. The surrogate application copieswhich reside and operate in the RVM 179 during the offloading timeperiods can communicate to third-party servers or proxies via the RVM179 (e.g., through network connections, or through third-party proxy 199or 110) in carrying out normal operations in substitution of theapplications 102 or 163 on the client device 150.

Notification Server 141: The notification server 141 is a module able toconnect to an operator's SMSC gateways and deliver SMS notifications tothe client-side proxy 175. SMS notifications can be used when an IP linkis not currently active, in order to avoid the client-side proxy 175from activating a connection over the wireless data channel, thusavoiding additional signaling traffic. However, if the IP connectionhappens to be open for some other traffic, the notification server 141can use it for sending the notifications to the client-side proxy 175.The user database can store operational data including endpoint(MSISDN), organization and Notification server 141 gateway for eachresource (URIs or URLs).

Traffic Harmonizer 144: The traffic harmonizer 144 can be responsiblefor communication between the client-side proxy 175 and the pollingserver 145. The traffic harmonizer 144 connects to the polling server145 directly or through the data storage 130, and to the client over anyopen or proprietary protocol such as the 7TP, implemented for trafficoptimization. The traffic harmonizer 144 can be also responsible fortraffic pipelining on the server side: if there's cached content in thedatabase for the same client, this can be sent over to the client in onemessage.

Polling Server 145: The polling server 145 can poll third partyapplication servers on behalf of applications that are being optimized).If a change occurs (i.e. new data available) for an application, thepolling server 145 can report to the traffic harmonizer 144 which inturn sends a notification message to the client-side proxy 175 for it toclear the cache and allow application to poll application serverdirectly.

Policy Management Server 143: The policy management server (PMS) 143allows administrators to configure and store policies for theclient-side proxies 175 (device clients). It also allows administratorsto notify the client-side proxies 175 about policy changes. Using thepolicy management server 143, each operator can configure the policiesto work in the most efficient way for the unique characteristics of eachparticular mobile operator's network.

Reporting and Usage Analytics Component: The Reporting and UsageAnalytics component or system collects information from the client side175 and/or from the server side 125, and provides the tools forproducing reports and usage analytics that operators can use foranalyzing application signaling and data consumption.

Most mobile applications regularly poll their application servers tocheck for new data. Often there is no new data or the content has notchanged, so the exchange of data through the mobile network isunnecessary. As the number of mobile phones and their applicationsincrease, the amount of this needless polling grows. Since applicationsare not coordinated and poll at different times and intervals, any givenphone may frequently generate signal traffic. This causes multipleunnecessary radio activations, consuming power and shortening batterylife.

In one embodiment, the signaling optimizer reduces network requests to aminimum by caching content in the client and letting its own server pollfor changes in the network. When a mobile phone's client side proxy(e.g., local proxy) 175 detects a recurring pattern for a resource, suchas an email application, its response content is stored locally in aclient cache so similar requests from that application get theirresponse from the local cache, rather than signaling the network.

FIG. 1G illustrates an example diagram of a signaling optimizer of thedistributed proxy and cache system.

As an example, someone who typically gets only 10 emails a day may havephone's email application poll the network for new email every 15minutes, or 96 times a day, with around 90% or more of the pollsresulting in the same response: there are no new emails. The client sideproxy (e.g., local proxy) 175 can recognize this request-responsepattern, and intercepts the application's poll requests, returning thelocally cached response of “no new emails”. This way the device radio isnot turned on by this particular application, and the poll doesn't useany network resources. The server (e.g., host server 100, proxy server125), located in the network, can monitor the email application serveron behalf of the user's email application. When new email is available,the server can notify the user's client-side proxy 175 to not use thecached “no new emails” response for the next poll request. Instead ofgoing to the local client cache, the email application polls itsapplication server over the network and receives the new content.

The signaling optimizer can be configured and managed using differentrule sets for different device types, user types, wireless networks, andapplications. Optimization rules can be updated at any time, so thechanges can be applied immediately when an application upgrades orchanges happen in the mobile network. The protocols that can beoptimized include, but are not limited to: HTTP, HTTPS and DNS.

FIG. 1H illustrates an example diagram of an example client-serverarchitecture of the distributed proxy and cache system.

In the client-server architecture, the client-side proxy 175 (e.g.,local proxy) is residing on the mobile or client devices. Theclient-side proxy 175 can communicate both directly to the Internet(usually via an operator proxy) and to the server side proxy (e.g.,proxy server) 125, or the host server 100. The proxy server 125communicates to the Internet and to the operator's SMSC 112.

As depicted, the client-side proxy 175 can send a request directly tothe Internet. This can happen after requests have been analyzed todetect optimizable patterns, for example. The client-side proxy 175 can,in one implementation, send a request to the server (e.g., host server100, proxy server 125), for example, to initiate server polling, toreports logs or to get new configuration. The proxy server 125 can senda request to the Internet to, for example, validate cached content. Inone implementation, the proxy server 125 can send a request to the SMSC112, for example, to send a cache invalidate message or policy updatemessage to the client-side proxy 175.

In one implementation, the client-side proxy 175 may not maintain anopen connection with the proxy server 125, but may connect to the proxyserver 125 only in case there's a need to start polling an origin server110, to report logs or to get new configuration. For signaling optimizerfeature, the proxy server 125 can notify the client-side proxy 175 whenthe content, that has been polled, has changed. The proxy server 125 cansend a request to invalidate cache in the client-side proxy 175. Whenthe application connects to that particular origin server (e.g., contentserver 110) the next time, it can first fetch the latest content fromthe proxy server 125 and then directly connect to the origin server 110.For the policy enforcer and/or the network protector features, the proxyserver 125 can notify the client-side proxy 175 when there's newconfiguration to be fetched from the server. When the proxy server 125needs to communicate with the client-side proxy 175, it can use aconnection that is already open for some other request. If theconnection is not open, the proxy server 125 can send a notification(e.g., SMS) to the client-side proxy 175.

FIG. 1I depicts an example diagram illustrating data flows betweenexample client side components in a distributed proxy and cache system.Traffic from applications (e.g., App1, App2, App3 to AppN), client sideproxy (e.g., local proxy) 175, IP Routing Tables (e.g., in the AndroidOperating System Layer), Network Access Layer and Wireless Network aredepicted.

In one implementation, non-optimized application traffic flow, such astraffic from App1, can completely bypass the client-side proxy 175components and proceed directly through the operating system layer(e.g., the Android OS layer) and Network Access Layer to the wirelessnetwork. Traffic that that is not optimized can include, but is notlimited to: rich media, like video and audio, as well as traffic fromnetworks and applications that has been configured to bypassoptimization and traffic pending optimization, and the like. In oneembodiment, all traffic can be configured to bypass the clientside/server side proxy.

In another implementation, optimized application traffic, such astraffic from App2, can be redirected from the application to theclient-side proxy 175. By default, this can be traffic on ports 80(HTTP) and 53 (DNS), and selected traffic on port 443 (HTTPS), forexample. However, traffic to other ports can be configured to bedirected to the client side proxy.

In yet another implementation, traffic flow can be between theclient-side proxy 175 and the origin servers (e.g., content server 110)via the Internet and/or between the client-side proxy 175 and the serverside proxy (e.g., proxy server) 125.

FIG. 2 depicts example functional components of a mobile device 250implementing an application offloading engine2.

The mobile device 250 can include one or more applications 210A-210N, anoperating system (OS) 230, other platform specific and/or other modules220 such as network interface components, sensor components, nativeapplications, etc., other components described in FIG. 1E, and the like.The application offload engine 205, in some embodiments, can include anapplication state manager 206 (e.g., application state manager 107 ofFIG. 1A) and a transfer manager 214 (e.g., transfer manager 109 of FIG.1A). In some embodiments, the application state manager 206 can includean optimal time setting module 208 and the transfer manager 214 caninclude an application synchronization module 216. Additional or lessmodules or components can be included in the application offload engine205. Depending on the implementation, one or more of the components canbe consolidated into a single component, and/or a single component canbe further divided into multiple components.

According to some embodiments, the application offload engine 205 canperform mobile application offloading to reduce unnecessary power, dataconsumption, and/or other resources on the mobile device 250 whilemaintaining functionalities of the applications.

In some embodiments, the application state manager 206 can determine oneor more time periods for performing the offloading techniques. Forexample, the optimal time setting module 208 can obtain informationabout the mobile device's operation including, for example, networkusage, battery, CPU, memory and/or other resources. The information canbe provided to the optimal time setting module 208 via, for example, thedevice state monitor 121 described in relation to FIG. 1E. In someembodiments, the optimal time setting module 208 can receiveinstructions regarding the offloading time period(s) from a user, theapplication developer, the carrier or network operator, the devicemanufacturer, or the like. Some instructions may be given priority overothers and may be received from either one or more input mechanisms onthe device 250 or from the network 117 (FIG. 1A). Examples of theseoffloading time periods include off-peak or late night hours (e.g., from10:00 PM to 6:00 AM) or during a time period in which low user activityor low battery power is detected. In some embodiments, the applicationstate manager 206 can detect operation of a data intensive applicationon the mobile device and trigger the optimal time setting module 208 tooffload operation of other mobile applications on the mobile device to aremote server. The offloading in this instance allows the mobile deviceto allocate more resources to the data intensive application that theuser is interacting with and as a result, improves the user experience.

The optimal time setting module 208, in determining the time period(s),can employ one or more suitable heuristics or algorithms, and canreceive aids from a resource usage pattern detector 212 or othersuitable tools. The resource usage pattern detector 212 can detectpatterns of usage of resources such as CPU, memory, battery, network, orthe like by applications. For example, one pattern that the resourceusage pattern detector 212 can detect can be consumption of a largeamount of network resource by an application 210A between 10 pm and 6am. In some embodiments, the user can instruct the application statemanager 206 in selecting which one or more of the applications (e.g.,applications 210A-N) should be offloaded according to the techniquesdisclosed herein.

According to the determined, user specified, operator specified,carrier/network operator specified time period, or conditions whichwarrant for example, partial application function/feature offloading,the application state manager 206 can suspend one or more selectapplications on the mobile device 250 so that the suspended applicationsbecome dormant or go into hibernation. When a suspended application goesinto hibernation, the typical computing power and other resourcesconsumption associated with that application on the device can bereduced or, in some embodiments, substantially or totally removed.

Upon the suspension of the application, the transfer manager 214 caninitiate a transfer of functions and/or operation data of the suspendedapplication to a remote virtual machine (e.g., RVM 113A, FIG. 1A) toestablish an application copy (e.g., application copy 115A, FIG. 1A)operating on the remote virtual machine as a surrogate of the suspendedapplication on the device 250. The remote virtual machine in thecloud-based environment is located on a remote server (e.g., server 111,FIG. 1A) that is separated from the mobile device. In some embodiments,the remote virtual machine uniquely corresponds to the mobile device 250and is able to emulate the computer architecture, specifications, andfunctions of the mobile device 250 (e.g., emulating the mobile devicehardware and its operating system environment, as well as otherconfiguration and/or preferences). Specifically, the applicationsynchronization module 216 in the transfer manager 214 manages thetransfer and/or receipt of any data that is necessary or relevant to thenormal operations of the suspended application to ensure the timeliness,accuracy and/or consistency of the data.

The remote virtual machine can execute the application copy in a same orsimilar way as how the mobile device 250 executes the originalapplication. Also, the application copy operating on the remote virtualmachine can communicate to one or more third-party servers (e.g.,third-party servers 119A-N, FIG. 1A) in a same or similar way as how theoriginal application on the mobile device 250 communicates to thethird-party servers. In this way, the application copy continues tonormally operate in the remote virtual machine and communicate with thethird-party servers (e.g., via network 117), even when the application'soperation is suspended on the mobile device 250. In those embodimentswhich the third-party servers (e.g., third-party server 119A-N) comprisethe remote virtual machines, the application copy can communicatedirectly with the third-party servers.

Upon the expiration of the offloading time period, the data generatedduring the application copy's operations on the remote virtual machineare transferred back to the mobile device 250. The transfer back processcan be initiated by the mobile device 250 (e.g., via the transfermanager 214), by the server hosting the remote virtual machines, or byany other suitable entity such as an administrator or a policy makerassociated with the server. The transfer manager 214 receives the datafrom the server, and the application synchronization module 216 updatesany changes from the received data to the suspended application on thedevice 250.

In some embodiments, the application operation data (e.g., applicationID, bundle ID, version number, user credentials, settings/preferences,and so forth) that are necessary to set up and configure a correspondingapplication copy on a remote virtual machine can be transferred from themobile device 250 to the server 111. Additionally or alternatively,application functions (e.g., receiving a certain type of pushnotifications, and/or polling third-party servers for a certain type ofupdates) can be transferred from the mobile device 250 to the server111.

In other embodiments, the application's functions and/or operation datacan be transferred once during an initial offloading session, and anysubsequent change (e.g., configuration, credential, and/or othersuitable attributes) can be transferred in subsequent offloadingsessions. In yet other embodiments, the application's functions and/oroperation data can be transferred at each or one or more selectoffloading sessions.

It is also noted that, in some embodiments, it is not necessary totransfer the application's functions and/or operation data from theserver 111 back to the mobile device 250 after the offloading session(s)is over. In these embodiments, only the updates/changes to thoseoperation data are transferred back.

After the update, the application state manager 206 resumes the normaloperations of the previously suspended application 210A on the mobiledevice 250. It is noted that the functionalities of various elements orcomponents described in the application offload engine 205 and/or remotevirtual machine are merely exemplary, as they may be logically and/orphysically distributed across multiple components or be grouped intoseveral components. For example, as previously discussed, embodimentsshown in FIGS. 1E-1F illustrates how the application offload engine 205and/or remote virtual machines can be implemented within adistributed-proxy system.

In some embodiments, the transfer to and from the server hosting theremote virtual machines is encrypted and secured by one or more suitableencryption algorithms. In some embodiments, the user or theadministrator of the mobile device 250 can control and access the remotevirtual machine. Also, in some embodiments, when the data and/orfunctions of a suspended application are transferred from the mobiledevice to the server (e.g., server 111) and when the data or updates tothe data are transferred back from the server (e.g., server 111) to themobile device 250, one or more data compression techniques (e.g., lossless compression, lossy less compression) can be applied to furtherreduce data and/or power consumption.

In this way, among other benefits, the offloading techniques disclosedherein bring the benefit of resource savings from suspending theapplication on the mobile device while maintaining normal operations ofthe suspended application without any loss of data.

FIG. 3A depicts an example flow diagram illustrating a method 300A ofmobile application offloading. The method 300A can be implemented on,for example, a user mobile device (e.g., mobile device 150, FIG. 1A-1L,device 250, FIG. 2). With general reference to FIGS. 1A-1B and 2-3, themethod 300A is now described.

First, at block 310, a time setting module (e.g., optimal time settingmodule 208, FIG. 2) of an application offload engine (e.g., applicationoffload engine 205, FIG. 2) on a mobile device 250 determines a timeperiod (e.g., at optimal times such as night time, user configured timesor inactive times) for suspending operation or functioning of anapplication (e.g., any application 210A-N, FIG. 2) on the mobile device250. The optimal time setting module 208 can determine the timeperiod(s) based system information about the device 250, instructionsfrom the user, network carrier/operator, instructions from anadministrator, other suitable data, or a combination thereof.

According to the determined time period, at block 320, an applicationstate manager (e.g., application state manager 206, FIG. 2) of theapplication offload engine 205 suspends an application on the mobiledevice 250. When the application is suspended, the typical computingpower and other resources consumption associated with operating theapplication on the device 250 can be greatly reduced or, in someembodiments, totally removed.

Approximately upon the suspension of the application, at block 330, atransfer manager (e.g., manager 214) of the application offload engine205 transfers operation data and/or functions of the suspendedapplication to a remote virtual machine (e.g., virtual machine 113A,FIG. 1A) to establish an application copy (e.g., application copy 115A,FIG. 1A) operating on the virtual machine as a surrogate of thesuspended application on the mobile device 250. In some embodiments,data associated with the suspended application are transferred to theremote virtual machine. Additionally or alternatively, functionsassociated with the suspended application can also be transferred. Insome other embodiments, a duplicate software copy of the suspendedapplication can be transferred.

The virtual machine, for example, of the cloud-based environment can behosted or located (335) on a remote server (e.g., server 111) that isremote to the mobile device 250. In some embodiments, the remote servercan be a part of a host server that hosts other conservation functions(host server 100, FIG. 1B). In some other embodiments, the remote servercan be hosted by or can be a part of a third-party server (e.g.,third-party server 119A, FIG. 1A; server 110, FIG. 1B).

Upon expiration of the determined time period, at block 340, thetransfer manager 214 receives (e.g., manager 214, FIG. 2) updates to thedata received or generated during the time period when the applicationcopy was being executed on the remote virtual machine. In someembodiments, only the relevant updates/changes are transferred back. Inother embodiments, all data can be transferred back. The transfer can beinitiated by the mobile device 250 (e.g., via the transfer manager 214)or by the server 111 or by other suitable entities.

After receiving the data or the updates/changes to the data, anapplication synchronization module (e.g., application synchronizationmodule 216, FIG. 2) updates the suspended application on the mobiledevice 250 based on the received data at block 350. The applicationstate manager 206 then resumes operation of the suspended application onthe mobile device 250 at block 360.

FIG. 3B depicts an example flow diagram illustrating a method 300B ofexecuting an application copy of a mobile application. The method startsat block 362, when a virtual machine on a server or a server cloudreceives configuration data to establish a copy of a mobile applicationinstalled on a mobile device. At block 364, the virtual machineestablishes a copy of the mobile application based on the configurationdata. At block 366, the virtual machine receives instructions to executethe application copy for a period of time and in response to receivingthe instructions, executes the copy of the mobile application for theperiod of time in the same manner as the mobile device would execute themobile application at block 368. The period of time can be included inthe instructions and can be determined based on user behavior, usersettings or a state of the mobile application.

At block 370, the virtual machine aggregates new or changed data fromexecuting the copy of the mobile application and at the end of theperiod of time, transfers the new or changed data that are aggregated tothe mobile application on the mobile device at block 372.

While the copy of the mobile application is being executed at thevirtual machine, the mobile application remains in a paused or suspendedstate to reduce consumption of resources by the mobile application onthe mobile device. In the paused or suspended, the mobile applicationconsumes limited or no resources at all. When the new or changed data istransferred to the mobile application at the end of the period of time,the transferred data updates the mobile application and causes themobile application exit the paused state and resume normal operation.

FIG. 4 shows a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

In the example of FIG. 4, the computer system 400 includes a processor,memory, non-volatile memory, and an interface device. Various commoncomponents (e.g., cache memory) are omitted for illustrative simplicity.The computer system 400 is intended to illustrate a hardware device onwhich any of the components depicted in the example of FIG. 2 (and anyother components described in this specification) and the methods 300Aand 300B depicted in FIGS. 3A and 3B can be implemented. The computersystem 400 can be of any applicable known or convenient type. Thecomponents of the computer system 400 can be coupled together via a busor through some other known or convenient device.

The processor may be, for example, a conventional microprocessor such asan Intel Pentium microprocessor or Motorola power PC microprocessor. Oneof skill in the relevant art will recognize that the terms“machine-readable (storage) medium” or “computer-readable (storage)medium” include any type of device that is accessible by the processor.

The memory is coupled to the processor by, for example, a bus. Thememory can include, by way of example but not limitation, random accessmemory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM). Thememory can be local, remote, or distributed.

The bus also couples the processor to the non-volatile memory and driveunit. The non-volatile memory is often a magnetic floppy or hard disk, amagnetic-optical disk, an optical disk, a read-only memory (ROM), suchas a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or anotherform of storage for large amounts of data. Some of this data is oftenwritten, by a direct memory access process, into memory during executionof software in the computer system 400. The non-volatile storage can belocal, remote, or distributed. The non-volatile memory is optionalbecause systems can be created with all applicable data available inmemory. A typical computer system usually includes at least a processor,memory, and a device (e.g., a bus) coupling the memory to the processor.

Software is typically stored in the non-volatile memory and/or the driveunit. Indeed, for large programs, it may not even be possible to storethe entire program in the memory. Nevertheless, it should be understoodthat for software to run, if necessary, it is moved to a computerreadable location appropriate for processing, and for illustrativepurposes, that location is referred to as the memory in this paper. Evenwhen software is moved to the memory for execution, the processortypically make use of hardware registers to store values associated withthe software, and local cache that, ideally, serves to speed upexecution. As used herein, a software program is assumed to be stored atany known or convenient location (from non-volatile storage to hardwareregisters) when the software program is referred to as “implemented in acomputer-readable medium.” A processor is considered to be “configuredto execute a program” when at least one value associated with theprogram is stored in a register readable by the processor.

The bus also couples the processor to the network interface device. Theinterface can include one or more of a modem or network interface. Itwill be appreciated that a modem or network interface can be consideredto be part of the computer system. The interface can include an analogmodem, isdn modem, cable modem, token ring interface, satellitetransmission interface (e.g. “direct PC”), or other interfaces forcoupling a computer system to other computer systems. The interface caninclude one or more input and/or output devices. The I/O devices caninclude, by way of example but not limitation, a keyboard, a mouse orother pointing device, disk drives, printers, a scanner, and other inputand/or output devices, including a display device. The display devicecan include, by way of example but not limitation, a cathode ray tube(CRT), liquid crystal display (LCD), or some other applicable known orconvenient display device. For simplicity, it is assumed thatcontrollers of any devices not depicted in the example of FIG. 8 residein the interface.

In operation, the computer system 400 can be controlled by operatingsystem software that includes a file management system, such as a diskoperating system. One example of operating system software withassociated file management system software is the family of operatingsystems known as Windows®. Another example of operating system softwarewith its associated file management system software is the Linuxoperating system and its associated file management system. The filemanagement system is typically stored in the non-volatile memory and/ordrive unit and causes the processor to execute the various acts requiredby the operating system to input and output data and to store data inthe memory, including storing files on the non-volatile memory and/ordrive unit.

Some portions of the detailed description may be presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantities take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the methods of some embodiments. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the techniques are not described withreference to any particular programming language, and variousembodiments may thus be implemented using a variety of programminglanguages.

In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aclient machine in a client-server network environment, or as a peermachine in a peer-to-peer (or distributed) network environment.

The machine may be a server computer, a client computer, a personalcomputer (PC), a tablet PC, a laptop computer, a set-top box (STB), apersonal digital assistant (PDA), a cellular telephone, an iPhone, aBlackberry, a processor, a telephone, a web appliance, a network router,switch or bridge, or any machine capable of executing a set ofinstructions (sequential or otherwise) that specify actions to be takenby that machine.

While the machine-readable medium or machine-readable storage medium isshown in an exemplary embodiment to be a single medium, the term“machine-readable medium” and “machine-readable storage medium” shouldbe taken to include a single medium or multiple media (e.g., acentralized or distributed database, and/or associated caches andservers) that store the one or more sets of instructions. The term“machine-readable medium” and “machine-readable storage medium” shallalso be taken to include any medium that is capable of storing, encodingor carrying a set of instructions for execution by the machine and thatcause the machine to perform any one or more of the methodologies of thepresently disclosed technique and innovation.

In general, the routines executed to implement the embodiments of thedisclosure, may be implemented as part of an operating system or aspecific application, component, program, object, module or sequence ofinstructions referred to as “computer programs.” The computer programstypically comprise one or more instructions set at various times invarious memory and storage devices in a computer, and that, when readand executed by one or more processing units or processors in acomputer, cause the computer to perform operations to execute elementsinvolving the various aspects of the disclosure.

Moreover, while embodiments have been described in the context of fullyfunctioning computers and computer systems, those skilled in the artwill appreciate that the various embodiments are capable of beingdistributed as a program product in a variety of forms, and that thedisclosure applies equally regardless of the particular type of machineor computer-readable media used to actually effect the distribution.

Further examples of machine-readable storage media, machine-readablemedia, or computer-readable (storage) media include but are not limitedto recordable type media such as volatile and non-volatile memorydevices, floppy and other removable disks, hard disk drives, opticaldisks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital VersatileDisks, (DVDs), etc.), among others, and transmission type media such asdigital and analog communication links.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words “comprise,” “comprising,” and thelike are to be construed in an inclusive sense, as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to.” As used herein, the terms “connected,”“coupled,” or any variant thereof, means any connection or coupling,either direct or indirect, between two or more elements; the coupling ofconnection between the elements can be physical, logical, or acombination thereof. Additionally, the words “herein,” “above,” “below,”and words of similar import, when used in this application, shall referto this application as a whole and not to any particular portions ofthis application. Where the context permits, words in the above DetailedDescription using the singular or plural number may also include theplural or singular number respectively. The word “or,” in reference to alist of two or more items, covers all of the following interpretationsof the word: any of the items in the list, all of the items in the list,and any combination of the items in the list.

The above detailed description of embodiments of the disclosure is notintended to be exhaustive or to limit the teachings to the precise formdisclosed above. While specific embodiments of, and examples for, thedisclosure are described above for illustrative purposes, variousequivalent modifications are possible within the scope of thedisclosure, as those skilled in the relevant art will recognize. Forexample, while processes or blocks are presented in a given order,alternative embodiments may perform routines having steps, or employsystems having blocks, in a different order, and some processes orblocks may be deleted, moved, added, subdivided, combined, and/ormodified to provide alternative or subcombinations. Each of theseprocesses or blocks may be implemented in a variety of different ways.Also, while processes or blocks are at times shown as being performed inseries, these processes or blocks may instead be performed in parallel,or may be performed at different times. Further any specific numbersnoted herein are only examples: alternative implementations may employdiffering values or ranges.

The teachings of the disclosure provided herein can be applied to othersystems, not necessarily the system described above. The elements andacts of the various embodiments described above can be combined toprovide further embodiments.

Any patents and applications and other references noted above, includingany that may be listed in accompanying filing papers, are incorporatedherein by reference. Aspects of the disclosure can be modified, ifnecessary, to employ the systems, functions, and concepts of the variousreferences described above to provide yet further embodiments of thedisclosure.

These and other changes can be made to the disclosure in light of theabove Detailed Description. While the above description describescertain embodiments of the disclosure, and describes the best modecontemplated, no matter how detailed the above appears in text, theteachings can be practiced in many ways. Details of the system may varyconsiderably in its implementation details, while still beingencompassed by the subject matter disclosed herein. As noted above,particular terminology used when describing certain features or aspectsof the disclosure should not be taken to imply that the terminology isbeing redefined herein to be restricted to any specific characteristics,features, or aspects of the disclosure with which that terminology isassociated. In general, the terms used in the following claims shouldnot be construed to limit the disclosure to the specific embodimentsdisclosed in the specification, unless the above Detailed Descriptionsection explicitly defines such terms. Accordingly, the actual scope ofthe disclosure encompasses not only the disclosed embodiments, but alsoall equivalent ways of practicing or implementing the disclosure underthe claims.

While certain aspects of the disclosure are presented below in certainclaim forms, the inventors contemplate the various aspects of thedisclosure in any number of claim forms. For example, while only oneaspect of the disclosure is recited as a means-plus-function claim under35 U.S.C. § 112, ¶ 6, other aspects may likewise be embodied as ameans-plus-function claim, or in other forms, such as being embodied ina computer-readable medium. (Any claim intended to be treated under 35U.S.C. § 112, ¶ 6 begins with the words “means for”.) Accordingly, theapplicant reserves the right to add additional claims after filing theapplication to pursue such additional claim forms for other aspects ofthe disclosure.

What is claimed is:
 1. A method of offloading operations of a mobileapplication, comprising: establishing an application copy of a mobileapplication installed on a mobile device at a remote virtual machine;suspending the mobile application on the mobile device; and offloadingoperations of the mobile application to the application copy at theremote virtual machine for a period of time.
 2. The method of claim 1,wherein suspending the mobile application and offloading the operationsof the mobile application to the remote virtual machine for the periodof time reduces consumption of resources by the mobile application onthe mobile device.
 3. The method of claim 2, wherein offloading theoperations of the mobile application to the application copy at theremote virtual machine for the period of time reduces consumption of atleast two of power, data, memory or CPU resources by the mobileapplication on the mobile device.
 4. The method of claim 1, furthercomprising: receiving data generated or obtained by the application copyduring the period of time the operations of the mobile application wasoffloaded to the application copy; and updating the mobile applicationwith the received data.
 5. The method of claim 4, further comprising:resuming the mobile application on the mobile device upon updating themobile application with the received data, wherein the received dataincludes new or changed data.
 6. The method of claim 1, furthercomprising: determining the period of time during which the operationsof the mobile application are offloaded to the application copy at theremote virtual machine based on at least one of: user instructions, useractivity patterns or a state of the mobile application.
 7. The method ofclaim 1, further comprising: selecting the mobile application from aplurality of mobile applications on the mobile device for offloadingbased on user instructions.
 8. The method of claim 1, furthercomprising: tracking resource consumption by a plurality of mobileapplications on the mobile device; and selecting the mobile applicationfor offloading based on the resource consumption that is tracked.
 9. Themethod of claim 1, wherein establishing the application copy of themobile application on the mobile device at the remote virtual machineincludes transferring application data associated with the mobileapplication to the remote virtual machine to facilitate the applicationcopy to be executed on the remote virtual machine in the same manner themobile application would be executed on the mobile device.
 10. A mobiledevice, comprising: a memory; a processor disposed in communication withthe memory and configured to execute a plurality of instructions storedin the memory to: transfer configuration data corresponding to a mobileapplication on the mobile device to a remote server to establish a proxyof the mobile application on a virtual machine hosted by the remoteserver; suspend the mobile application on the mobile device; and offloadoperations of the mobile application to the proxy of the mobileapplication at the virtual machine for a period of time.